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Abstract 


This document summarizes an operator’s perception of the benefits 
that may be provided by intermediary devices that execute functions 
beyond normal IP forwarding. Such intermediary devices are often 
called "middleboxes". 


RFC 3234 defines a taxonomy of middleboxes and issues in the 
Internet. Most of those middleboxes utilize or modify application- 
layer data. This document primarily focuses on devices that observe 
and act on information carried in the transport layer, and especially 
information carried in TCP packets. 


Status of This Memo 


This document is not an Internet Standards Track specification; it is 
published for informational purposes. 


This is a contribution to the RFC Series, independently of any other 
RFC stream. The RFC Editor has chosen to publish this document at 
its discretion and makes no statement about its value for 
implementation or deployment. Documents approved for publication by 
the RFC Editor are not candidates for any level of Internet Standard; 
see Section 2 of RFC 7841. 


Information about the current status of this document, any errata, 


and how to provide feedback on it may be obtained at 
https://www.rfc-editor.org/info/rfc8517. 
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1. Introduction 


From [RFC3234], "A middlebox is defined as any intermediary device 
performing functions other than the normal, standard functions of an 
IP router on the datagram path between a source host and destination 
host." 


Middleboxes are usually (but not exclusively) deployed at locations 
permitting observation of bidirectional traffic flows. Such 
locations are typically points where leaf networks connect to the 
Internet, for example: 


o Where a residential or business customer connects to its service 
provider(s), which may include multihoming; 


o On the Gi interface where a Gateway General Packet Radio Service 
(GPRS) Support Node (GGSN) connects to a Packet Data Network (PDN) 
(Section 3.1 of [RFC6459]). 


For the purposes of this document (and to be consistent with the 
definition in RFC 3234), middlebox functions may be found in routers 
and switches in addition to dedicated devices. 


This document itemizes a variety of features provided by middleboxes 
and by ad hoc analysis performed by operators using packet analyzers. 


Many of the techniques described in this document require stateful 
analysis of transport streams. A generic state machine is described 
in [PATH-STATE]. 


This document summarizes an operator’s perception of the benefits 
that may be provided by middleboxes. A primary goal is to provide 
information to the Internet community to aid understanding of what 
might be gained or lost by decisions that may affect (or be affected 
by) middlebox operation in the design of new transport protocols. 
See Section 1.1 for more details. 


1.1. Operator Perspective 


Network operators are often the ones first called upon when 
applications fail to function properly, often with user reports about 
application behaviors (not about packet behaviors). Therefore, it 
isn’t surprising that operators (wanting to be helpful) desire some 
visibility into flow information to identify how well the problem 
flows are progressing and how well other flows are progressing. 
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Advanced service functions (e.g., Network Address Translators (NATs), 
firewalls, etc.) [RFC7498] are widely used to achieve various 
objectives such as IP address sharing, firewalling, avoiding covert 
channels, detecting and protecting against ever-increasing 
Distributed Denial of Service (DDoS) attacks, etc. For example, 
environment-specific designs may require a number of service 
functions, such as those needed at the Gi interface of a mobile 
infrastructure [USE-CASE]. 


These sophisticated service functions are located in the network but 
also in service platforms or intermediat ntities (e.g., Content 
Delivery Networks (CDNs)). Network maintenance and diagnostic 
operations are complicated, particularly when responsibility is 
shared among various players. 


Network Providers are challenged to deliver differentiated services 
as a competitive business advantage while mastering the complexity of 
the applications, (continuously) evaluating the impacts on 
middleboxes, and enhancing customers’ quality of experience. 


Despite the complexity, removing all those service functions is not 
an option because they are used to address constraints that are often 
typical of the current (and changing) Internet. Operators must deal 
with constraints such as global IPv4 address depletion and support a 
plethora of services with different requirements for QoS, security, 
robustness, etc. 


1.2. Scope 


Although many middleboxes observe and manipulate application-layer 


content (e.g., session boarder controllers [RFC5853]), they are out 
of scope for this document, the aim being to describe middleboxes 
using transport-layer features. [RFC8404] describes the impact of 


pervasive encryption of application-layer data on network monitoring, 
protecting, and troubleshooting. 


The current document is not intended to recommend (or prohibit) 
middlebox deployment. Many operators have found the value provided 
by middleboxes to outweigh the added cost and complexity; this 
document attempts to provide that perspective as a reference in 
discussion of protocol design trade-offs. 


This document is not intended to discuss issues related to 
middleboxes. These issues are well known and are recorded in 
existing documents such as [RFC3234] and [RFC6269]. This document 
aims to elaborate on the motivations leading operators to enable such 
functions in spite of complications. 
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This document takes an operator perspective that measurement and 
management of transport connections is of benefit to both parties: 

th nd user receives a better quality of experience, and the network 
operator improves resource usage, the former being a consequence of 
the latter. 


This document does not discuss whether exposing some data to on-path 
devices for network-assistance purposes can be achieved by using 
in-band or out-of-band mechanisms. 


2. Measurements 


A number of measurements can be made by network devices that are 
either on-path or off-path. These measurements can be used either by 
automated systems or for manual network troubleshooting purposes 
(e.g., using packet-analysis tools). The automated systems can 
further be classified into two types: 1) monitoring systems that 
compute performance indicators for single connections or aggregates 
of connections and generate aggregated reports from them; and 2) 
active systems that make decisions also on how to handle packet flows 
based on these performance indicators. 


Long-term trends in these measurements can aid an operator in 
capacity planning. 


Short-term anomalies revealed by these measurements can identify 
network breakages, attacks in progress, or misbehaving devices/ 
applications. 


2.1. Packet Loss 


It is very useful for an operator to be able to detect and isolate 
packet loss in a network. 


Network problems and underprovisioning can be detected if packet loss 


is measurable. TCP packet loss can be detected by observing gaps in 
sequence numbers, retransmitted sequence numbers, and selective 
acknowledgement (SACK) options [RFC2018]. Packet loss can be 


detected per direction. 


Gaps indicate loss upstream of the traffic observation point; 
retransmissions indicate loss downstream of the traffic observation 
point. SACKs can be used to detect either upstream or downstream 
packet loss (although some care needs to be taken to avoid 
misidentifying packet reordering as packet loss) and to distinguish 
between upstream versus downstream losses. 
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Packet-loss measurements on both sides of the measurement point are 
an important component in precisely diagnosing insufficiently 
dimensioned devices or links in networks. Additionally, packet 
losses are one of the two main ways for congestion to manifest, the 
others being queuing delay or Explicit Congestion Notification (ECN) 
[RFC3168]; therefore, packet loss is an important measurement for any 
middlebox that needs to make traffic handling decisions based on 
observed levels of congestion. 


2.2. Round-Trip Times 


The ability to measure partial-path round-trip times (RTITs) is 
valuable in diagnosing network issues (e.g., abnormal latency, 
abnormal packet loss). Knowing if latency is poor on one side of the 
observation point or the other provides more information than is 
available at either endpoint, which can only observe full RTTs. 


For example, a TCP packet stream can be used to measure the RTT on 
each side of the measurement point. During the connection handshake, 
the SYN, SYN/ACK, and ACK timings can be used to establish a baseline 
RTT in each direction. Once the connection is established, the RTT 
between the server and the measurement point can only reliably be 
determined using TCP timestamps [RFC7323]. On the side between th 
measurement point and the client, the exact timing of data segments 
and ACKs can be used as an alternative. For this latter method to be 
accurate when packet loss is present, the connection must use 
selective acknowledgements. 


In many networks, congestion will show up as increasing packet 
queuing, and congestion-induced packet loss will only happen in 
extreme cases. RTITs will also show up as a much smoother signal than 
the discrete packet-loss events. This makes RTTs a good way to 
identify individual subscribers for whom the network is a bottleneck 
at a given time or geographical sites (such as cellular towers) that 
are experiencing large-scale congestion. 


The main limit of RIT measurement as a congestion signal is the 
difficulty of reliably distinguishing between the data segments being 
queued versus the ACKs being queued. 


2.3. Measuring Packet Reordering 


If a network is reordering packets of transport connections, caused 
perhaps by Equal-Cost Multipath (ECMP) misconfiguration (described in 
[RFC2991] and [RFC7690], for example), the endpoints may react as if 
packet loss is occurring and retransmit packets or reduce forwarding 
rates. Therefore, a network operator desires the ability to diagnose 
packet reordering. 
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For TCP, packet reordering can be detected by observing TCP sequence 


numbers per direction. See, for example, a number of standard 
packet-reordering metrics in [RFC4737] and informational metrics in 
[RFC5236]. 


2.4. Throughput and Bottleneck Identification 


Although throughput to or from an IP address can be measured without 
transport-layer measurements, the transport layer provides clues 
about what the endpoints were attempting to do. 


One way of quickly excluding the network as the bottleneck during 
troubleshooting is to check whether the speed is limited by the 
endpoints. For example, the connection speed might instead be 
limited by suboptimal TCP options, the sender’s congestion window, 
the sender temporarily running out of data to send, the sender 
waiting for the receiver to send another request, or the receiver 
closing the receive window. 


This data is also useful for middleboxes used to measure network 
quality of service. Connections, or portions of connections, that 
are limited by the endpoints do not provide an accurate measure of 
the network’s speed and can be discounted or completely excluded in 
such analyses. 


2.5. Congestion Responsiveness 
Congestion control mechanisms continue to evolve. Tools exist that 
can interpret protocol sequence numbers (e.g., from TCP or RTP) to 


infer the congestion response of a flow. Such tools can be used by 
operators to help understand the impact of specific transport 
protocols on other traffic that shares their network. For example, 
packet sequence numbers can be analyzed to help understand whether an 
application flow backs off its load in the face of persistent 
congestion (as TCP does) and, hence, whether the behavior is 
appropriate for sharing limited network capacity. 


These tools can also be used to determine whether mechanisms are 
needed in the network to prevent flows from acquiring excessive 
network capacity under severe congestion (e.g., by deploying rate 
limiters or network transport circuit breakers [RFC8084]). 
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2.6. Attack Detection 


When an application or network resource is under attack, it is useful 
to identify this situation from the network perspective, upstream of 
the attacked resource. 


Although detection methods tend to be proprietary, attack detection 
from within the network may comprise: 


o Identifying uncharacteristic traffic volumes or sources; 


o Identifying congestion, possibly using techniques in Sections 2.1 
and 2.2; 


o Identifying incomplete connections or transactions, from attacks 
that attempt to exhaust server resources; 


o Fingerprinting based on whatever available fields are determined 
to be useful in discriminating an attack from desirable traffic. 


Two trends in protocol design will make attack detection more 
difficult: 


o The desire to encrypt transport-layer fields; 


o The desire to avoid statistical fingerprinting by adding entropy 
in various forms. 


While improving privacy, those approaches may hinder attack 
detection. 


2.7. Packet Corruption 


One notable source of packet loss is packet corruption. This 
corruption will generally not be detected until the checksums are 
validated by the endpoint and the packet is dropped. This means that 
detecting the exact location where packets are lost is not sufficient 
when troubleshooting networks. An operator would like to find out 
where packets are being corrupted. IP and TCP checksum verification 
allows a measurement device to correctly distinguish between upstream 
packet corruption and normal downstream packet loss. 


Transport protocol designers should consider whether a middlebox will 
be able to detect corrupted or tampered packets. 
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2.8. Application-Layer Measurements 


Information about network health may also be gleaned from 
application-layer diagnosis, such as: 


o DNS response times and retransmissions calculated by correlating 
answers to queries; 


o Various protocol-aware voice and video quality analyses. 
Could this type of information be provided in a transport layer? 


3. Functions beyond Measurement: A Few Examples 


This section describes features provided by on-path devices that go 
beyond measurement by modifying, discarding, delaying, or 
prioritizing traffic. 


3.1. NAT 


Network Address Translators (NATs) allow multiple devices to share a 
public address by dividing the transport-layer port space among the 
devices. 


NAT behavior recommendations are found for UDP in BCP 127 [RFC4787] 
and for TCP in BCP 142 [RFC7857]. 


To support NAT, there must be transport-layer port numbers that can 
be modified by the NAT. Note that required fields (e.g., port 
numbers) are visible in all IETF-defined transport protocols. 


The application layer must not assume the port number was left 
unchanged (e.g., by including it in a checksum or signing it). 


Address sharing is also used in the context of IPv6 transition. For 
example, DS-Lite Address Family Transition Router (AFTR) [RFC6333], 
NAT64 [RFC6146], or A+P [RFC7596] [RFC7597] are features that are 
enabled in the network to allow for IPv4 service continuity over an 
IPv6 network. 


Further, because of some multihoming considerations, IPv6 prefix 
translation may be enabled by some enterprises by means of IPv6-to- 
IPv6 Network Prefix Translation (NPTv6) [RFC6296]. 
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3.2. Firewall 


Firewalls are pervasive and essential components that inspect 
incoming and outgoing traffic. Firewalls are usually the cornerstone 
of a security policy that is enforced in end-user premises and other 
locations to provide strict guarantees about traffic that may be 
authorized to enter/leave the said premises, as well as end users who 
may be assigned different clearance levels regarding which networks 
and portions of the Internet they access. 


An important aspect of a firewall policy is differentiating 
internally initiated from externally initiated communications. 


For TCP, this is easily done by tracking the TCP state machine. 
Furthermore, th nding of a TCP connection is indicated by RST or 
FIN flags. 


For UDP, the firewall can be opened if the first packet comes from 
an internal user, but the closing is generally done by an idle 
timer of arbitrary duration, which might not match the 
expectations of the application. 


Simple IPv6 firewall capabilities for customer premises equipment 
(both stateless and stateful) are described in [RFC6092]. 


A firewall functions better when it can observe the protocol state 
machine, described generally by "Transport-Independent Path Layer 
State Management" [PATH-STATE]. 


3.3. DDoS Scrubbing 


In the context of a DDoS attack, the purpose of a scrubber is to 
discard attack traffic while permitting useful traffic. Sucha 
mitigator is described in [DOTS]. 


When attacks occur against constrained resources, some traffic will 
be discarded before reaching the intended destination. A user 
receives better experience and a server runs more efficiently if a 
scrubber can discard attack traffic, leaving room for legitimate 
traffic. 


Scrubbing must be provided by an on-path network device, because 
neither endpoint of a legitimate connection has any control over the 
source of the attack traffic. 


Source-spoofed DDoS attacks can be mitigated at the source using BCP 


38 [RFC2827], but it is more difficult if source address filtering 
cannot be applied. 
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In contrast to devices in the core of the Internet, middleboxes 
statefully observing bidirectional transport connections can reject 
source-spoofed TCP traffic based on the inability to provide sensible 
acknowledgement numbers to complete the three-way handshake. 
Obviously, this requires middlebox visibility into a transport-layer 
state machine. 


Middleboxes may also scrub on the basis of statistical 
classification: testing how likely a given packet is to be 
legitimate. As protocol designers add more entropy to headers and 
lengths, this test becomes less useful, and the best scrubbing 
strategy becomes random drop. 


3.4. Implicit Identification 


In order to enhance th nd user’s quality of experience, som 
operators deploy implicit identification features that rely upon the 
correlation of network-related information to access some local 
services. For example, service portals operated by some operators 
may be accessed immediately by end users without any explicit 
identification for the sake of improved service availability. This 
is doable thanks to on-path devices that inject appropriate metadata 
that can be used by the remote server to enforce per-subscriber 


policies. The information can be injected at the application layer 
or at the transport layer (when an address-sharing mechanism is in 
use). 


An experimental implementation using a TCP option is described in 
[RFC7974]. 


For the intended use of implicit identification, it is more secure to 
have a trusted middlebox mark this traffic than to trust end-user 
devices. 


3.5. Performance-Enhancing Proxies 


Performance-Enhancing Proxies (PEPs) can improve performance in some 
types of networks by improving packet spacing or generating local 
acknowledgements; they are most commonly used in satellite and 
cellular networks. Transport-Layer PEPs are described in 

Section 2.1.1 of [RFC3135]. 


PEPs allow central deployment of congestion control algorithms more 
suited to the specific network, most commonly for delay-based 
congestion control. More advanced TCP PEPs deploy congestion control 
systems that treat all of a single end user’s TCP connections as a 
single unit, improving fairness and allowing faster reaction to 
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changing network conditions. For example, it was reported that 
splitting the TCP connections in some network accesses can result in 
a halved page downloading time [ICCRG]. 


Local acknowledgements generated by PEPs speed up TCP slow start by 
splitting the effective latency, and they allow for retransmissions 
to be done from the PEP rather than from the actual sender. Local 
acknowledgements will also allow a PEP to maintain a local buffer of 
data appropriate to the actual network conditions, whereas the actual 
endpoints would often send too much or too little. 


A PEP function requires transport-layer fields that allow chunks of 
data to be identified (e.g., TCP sequence numbers), acknowledgements 
to be identified (e.g., TCP ACK numbers), and acknowledgements to be 
created from the PEP. 


Note that PEPs are only useful in some types of networks. In 
particular, PEPs are very useful in contexts wherein the congestion 
control strategies of the endpoints are inappropriate for the network 
connecting them. That being said, poor design can result in degraded 
performances when PEPs are deployed. 


3.6. Network Coding 


Network Coding is a technique for improving transmission performance 
over low-bandwidth, long-latency links such as some satellite links. 
Coding may involve lossless compression and/or adding redundancy to 
headers and payload. A Network Coding Taxonomy is provided by 
[RFC8406]; an example of end-to-end coding is FECFRAME [RFC6363]. It 
is typically deployed with network-coding gateways at each end of 
those links, with a network-coding tunnel between them via the 
slow/lossy/long-latency links. 


Network-coding implementations may be specific to TCP, taking 
advantage of known properties of the protocol. 


The network-coding gateways may employ some techniques of PEPs, such 
as creating acknowledgements of queued data, removing 
retransmissions, and pacing data rates to reduce queue oscillation. 


The interest in more network coding in some specific networks is 
discussed in [SATELLITES]. 


Note: This is not to be confused with transcoding, which performs 


lossy compression on transmitted media streams and is not in scope 
for this document. 


Dolson, et al. Informational [Page 12] 


RFC 8517 Transport-—Centric Middlebox Functions February 2019 


3.7. Network-Assisted Bandwidth Aggregation 


The Hybrid Access Aggregation Point is a middlebox that allows 
customers to aggregate the bandwidth of multiple access technologies. 


One of the approaches uses Multipath TCP (MPTCP) proxies 

[TCP-CONVERT] to forward traffic along multiple paths. The MPTCP 
proxy operates at the transport layer while being located in the 
operator’s network. 


The support of multipath transport capabilities by communicating 
hosts remains a privileged target design so that such hosts can 
directly use the available resources provided by a variety of access 
networks they can connect to. Nevertheless, network operators do not 
control end hosts, whereas the support of MPTCP by content servers 
remains marginal. 


Network-assisted MPTCP deployment models are designed to facilitate 
the adoption of MPTCP for the establishment of multipath 
communications without making any assumption about the support of 
MPTCP capabilities by communicating peers. Network-assisted MPTCP 
deployment models rely upon MPTCP Conversion Points (MCPs) that act 
on behalf of hosts so that they can take advantage of establishing 
communications over multiple paths [TCP-CONVERT]. 


Note there are cases when end-to-end MPTCP cannot be used even though 
both client and server are MPTCP-compliant. An MPTCP proxy can 
provide multipath utilization in these cases. Examples of such cases 
are listed below: 


1. The use of private IPv4 addresses in some access networks. 
Typically, additional subflows cannot be added to the MPTCP 
connection without the help of an MCP. 


2. The assignment of IPv6é prefixes only by some networks. If the 
server is IPv4-only, IPv6 subflows cannot be added to an MPTCP 
connection established with that server, by definition. 


3. Subscription to some service offerings is subject to volume 
quota. 
3.8. Prioritization and Differentiated Services 


Bulk traffic may be served with a higher latency than interactive 
traffic with no reduction in throughput. This fact allows a 
middlebox function to improve response times in interactive 
applications by prioritizing, policing, or remarking interactive 
transport connections differently from bulk-traffic transport 
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3. 


3: 


5. 


connections. For example, gaming traffic may be prioritized over 
email or software updates. Configuration guidelines for Diffserv 
service classes are discussed in [RFC4594]. 


Middleboxes may identify different classes of traffic by inspecting 
multiple layers of header and length of payload. 


9. Measurement-Based Shaping 


Basic traffic-shaping functionality requires no transport-—layer 
information. All that is needed is a way of mapping each packet to a 
traffic shaper quota. For example, there may be a rate limit per 
5-tuple or per subscriber IP address. However, such fixed traffic 
shaping rules are wasteful as they end up rate-limiting traffic even 
when the network has free resources available. 


More advanced traffic-shaping devices use transport-layer metrics 
described in Section 2 to detect congestion on either a per-site ora 
per-user level and use different traffic-shaping rules when 
congestion is detected [RFC3272]. This type of device can overcome 
limitations of downstream devices that behave poorly (e.g., by 
excessive buffering or suboptimally dropping packets). 


10. Fairness to End-User Quota 


Several service offerings rely upon a volume-based charging model 
(e.g., volume-based data plans offered by cellular providers). 
Operators may assist end users in conserving their data quota by 
deploying on-path functions that shape traffic that would otherwise 
be aggressively transferred. 


For example, a fast download of a video that won’t be viewed 
completely by the subscriber may lead to quick exhaustion of the data 
quota. Limiting the video download rate conserves quota for the 
benefit of the end user. Also, discarding unsolicited incoming 
traffic prevents the user’s quota from being unfairly exhausted. 


IANA Considerations 
This document has no IANA actions. 
Security Considerations 


1. Confidentiality and Privacy 


This document intentionally excludes middleboxes that observe or 
manipulate application-layer data. 
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The measurements and functions described in this document can all be 
implemented without violating confidentiality [RFC6973]. However, 
there is always the question of whether the fields and packet 
properties used to achieve operational benefits may also be used for 
harm. 


In particular, the question is what confidentiality is lost by 
exposing transport-layer fields beyond what can be learned by 
observing IP-layer fields: 


o Sequence numbers: an observer can learn how much data is 
transferred. 


o Start/Stop indicators: an observer can count transactions for some 
applications. 


o Device fingerprinting: an observer may be more easily able to 
identify a device type when different devices use different 


default field values or options. 


5.2. Active On-Path Attacks 


An on-path attacker being able to observe sequence numbers or session 
identifiers may make it easier to modify or terminate a transport 
connection. For example, observing TCP sequence numbers allows 
generation of a RST packet that terminates the connection. However, 
signing transport fields softens this attack. The attack and 
solution are described for the TCP authentication option [RFC5925]. 
Still, an on-path attacker can also drop the traffic flow. 


5.3. Improved Security 


Network maintainability and security can be improved by providing 
firewalls and DDoS mechanisms with some information about transport 
connections. In contrast, it would be very difficult to secure a 
network in which every packet appears unique and filled with random 
bits (from the perspective of an on-path device). 


Some features providing the ability to mitigate/filter attacks owing 
to a network-assisted mechanism will therefore improve security -- 
e.g., by means of Distributed-Denial-of-Service Open Threat Signaling 
(DOTS) [DOTS-SIGNAL] . 
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